Asynchronous gameplay with rival display

ABSTRACT

A user request to select a rival to play against asynchronously for an event is received. In response to the user request, a rival selector user interface is displayed. The rival selector UI includes an identification of one or more users that can be selected and one or more filter criteria that can be selected to change which users are identified in the rival selector UI. The user selects one of the identified users that is used as the rival to play against asynchronously for the event. Game data for the rival for the event is obtained, the game data including both a performance of the rival in the event and data indicating a manner in which an object of the rival is customized by the rival. While the user is playing the event, the object as customized by the rival is played back based on the performance data.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 61/542,256, filed Oct. 2, 2011, entitled “Asynchronous Gameplay withRival Display”, to Jonathan P. Knoles, et al., the disclosure of whichis hereby incorporated by reference herein in its entirety.

BACKGROUND

Online gaming services allow users to play games by themselves, or toplay games together with one or more other users. The online gamingservices typically maintain a leader board that ranks the various usersof a game based on the users' scores obtained while playing a game.Although such leader boards are useful to know how a user ranks againstother users in a game, they are not without their problems. One suchproblem is that if a user desires to try to beat another user byobtaining a higher score for a game, the user is typically presentedwith simply the score to beat. This creates an impersonal situation forthe user, providing an experience for the user that is more ofindividual gameplay rather than playing the game with another user.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

In accordance with one or more aspects, a user request to select a rivalto play against asynchronously for an event is received. In response tothe user request, a rival selector user interface is displayed. Therival selector user interface includes an identification of one or moreusers that can be selected. A user selection of one of the one or moreusers is received, and the selected user is used as the rival to playagainst asynchronously for the event.

In accordance with one or more aspects, a user request to play against arival asynchronously for an event is received. Game data for the rivalfor the event is obtained, the game data including both a performance ofthe rival in the event and data indicating a manner in which an objectof the rival is customized by the rival. While the user is playing theevent, the object as customized by the rival is played back based on theperformance data.

BRIEF DESCRIPTION OF THE DRAWINGS

The same numbers are used throughout the drawings to reference likefeatures.

FIG. 1 illustrates an example system implementing the asynchronousgameplay with rival display in accordance with one or more embodiments.

FIG. 2 illustrates an example gaming device and display in additionaldetail in accordance with one or more embodiments.

FIG. 3 illustrates an example system implementing the asynchronousgameplay with rival display in accordance with one or more embodiments.

FIGS. 4 and 5 illustrate example user interfaces allowing a user toselect a rival to play an event against asynchronously in accordancewith one or more embodiments.

FIGS. 6 and 7 illustrate an example of the changing of transparency ofan object representing a rival in accordance with one or moreembodiments.

FIG. 8 is a flowchart illustrating an example process for implementingthe asynchronous gameplay with rival display in accordance with one ormore embodiments.

FIG. 9 is a flowchart illustrating another example process forimplementing the asynchronous gameplay with rival display in accordancewith one or more embodiments.

FIG. 10 is a flowchart illustrating an example process for usingnotifications in accordance with one or more embodiments.

FIG. 11 illustrates an example computing device that can be configuredto implement the asynchronous gameplay with rival display in accordancewith one or more embodiments.

DETAILED DESCRIPTION

Asynchronous gameplay with rival display is discussed herein. When auser plays an event in a game, data regarding the user's performance inthat event is stored. A particular user can select another user (arival) to play against asynchronously in the event. A list identifyingvarious other users that have played the event can be displayed to theparticular user, and the list can be filtered in various manners (e.g.,based on friends of the particular user, scores of the users, and soforth). The particular user selects another user in the list as a rival,and an object representing the rival (e.g., the rival's vehicle) isdisplayed while the particular user plays the event. The objectrepresenting the rival is displayed with the rival's performance in theevent, providing the particular user with the experience of playing theevent with the rival even though the rival actually played the event atan earlier time. The object representing the rival is displayed withcustomizations made by the rival (e.g., particular paint colors ordesigns for a vehicle, particular stickers added to a vehicle, and soforth). If the particular user beats the score of the rival in theevent, then a currency or other credit is awarded to the particularuser. The currency or credit awarded is based on the particular user'sperformance and the score of the rival in the event. Additionally, ifthe particular user beats the score of the rival in the event, then anotification can be provided to the rival notifying him or her that heor she has been beaten in the event by the particular user. Thenotification includes a link that can be selected by the rival to jumpto the event, and to play the event again in an attempt to obtain abetter score than the particular user.

FIG. 1 illustrates an example system 100 implementing the asynchronousgameplay with rival display in accordance with one or more embodiments.System 100 includes multiple (x) gaming devices 102 and an online gamingservice 104 that can communicate with one another via a network 106.Network 106 can be a variety of different networks, including theInternet, a local area network (LAN), a wide area network (WAN), apersonal area network (PAN), a phone network, an intranet, other publicand/or proprietary networks, combinations thereof, and so forth.

Each gaming device 102 can be a variety of different types of devicesthat allow users to play games (such as racing games, sports games,strategy games, adventure games, simulation games, and so forth).Different ones of gaming devices 102 can be the same or different typesof devices. For example, a gaming device 102 can be a game console, acellular or other wireless phone, a television or other display device,a set-top box communicatively coupled to a display device, a desktopcomputer, a laptop or netbook computer, a tablet or notepad computer, amobile station, an entertainment appliance, an automotive computer, andso forth.

Online gaming service 104 facilitates playing of one or more differentgames by users of gaming devices 102. Gaming service 104 is referred toas being an online service due to gaming devices 102 accessing service104 (and/or other gaming devices 102) via network 106. Online gamingservice 104 includes an account access service 110, a gameplay service112, and optionally a matchmaking service 114, each of which cancommunicate with one another. Services 110, 112, and 114 can communicatewith one another within online gaming service 104 and/or via gamingdevices 102.

Account access service 110 provides various functionality supportinguser accounts of online gaming service 104. Different users and/orgaming devices 102 typically have different accounts with online gamingservice 104, and can log into their accounts via account access service110. A user or gaming device 102 logs into an account providingcredential information, such as an id (e.g., user name, email address,gamer tag, etc.) and password, a digital certificate or other data froma smartcard, and so forth. Account access service 110 verifies orauthenticates the credential information, allowing a user or gamingdevice 102 to access the account if the credential information isverified or authenticated, and prohibiting the user or gaming device 102from accessing the account if the credential information is not verifiedor is not authenticated. Once a user's credential information isauthenticated, the user can use the other services provided by onlinegamine service 104. Account access service 110 can also provide variousadditional account management functionality, such as permitting changesto the credential information, establishing new accounts, removingaccounts, and so forth.

Gameplay service 112 provides various functionality supporting playingof one or more different games by users of gaming devices 102. Differentgame titles can be supported by gameplay service 112 (e.g., one or moredifferent racing game titles, one or more different sports game titles,one or more different strategy game titles, and so forth). A game titlerefers to a particular set of instructions that implement a game whenexecuted (e.g., a set of instructions for a racing game from aparticular vendor, a set of instructions for a particular tennis gamefrom a particular vendor, etc.). A particular running of a game title isalso referred to as a game. Multiple games of the same game title can beplayed concurrently by different users, each game being a separaterunning of the game title. Games can be run and played as single-playergames in which a single user of a gaming device 102 is playing the gameand controlling one or more characters or other objects in the game,with other characters or objects in the game being controlled by thegame itself. Games can also be run and played as multi-player games inwhich multiple users of one or more gaming devices 102 are playing thesame game and each user is controlling one or more characters or otherobjects in the game. In multi-player games one or more additionalcharacters or other objects can also be controlled by the game itself.

A game is typically run by executing one or more programs. The programsthat are executed to run these games can be run on gaming devices 102and/or gameplay service 112. Gaming devices 102 can execute one or moreprograms for the game, communicating with gameplay service 112 tofacilitate communication between users of gaming devices 102 whileplaying games and/or to provide or obtain additional data (and/orprograms) for playing the game. Alternatively (or additionally),gameplay service 112 can execute one or more programs for the game,receiving inputs from users of gaming devices 102 and returning dataindicating outputs to be generated for display or other presentation tothe users of gaming devices 102.

In one or more embodiments, games are programs executed on gamingdevices 102 and gameplay service 112 manages communication betweendifferent gaming devices 102. In other embodiments, games are programsexecuted on gaming devices 102 and gameplay service 112 facilitatesestablishing communication between different gaming devices 102. Aftercommunication between two gaming devices 102 is established,communication can be made between those two gaming devices 102 withoutinvolving gameplay service 112.

Gameplay service 112 includes an asynchronous gameplay coordinationmodule 120. While playing a game, there is an object in the game thatrepresents the user. This object can vary based on the type of game,such as being a vehicle (e.g., a car, plane, boat, spaceship, etc.) in aracing game, being a graphical representation of a character (e.g., ahuman, alien, monster, etc.) in a shooting game, and so forth.Asynchronous gameplay coordination module 120 facilitates allowing usersto play events of games against one another asynchronously. Usersplaying events of games against one another asynchronously refers to theusers playing the events of the games at different times. One user(e.g., user A) plays an event in a game and user A's performance in theevent is recorded. The other user (e.g., user B) can play that sameevent at a later time, playing against the recording of user A'sperformance. Thus, both users play the same event, but do so atdifferent times. The users can be both logged in to online gamingservice 110 but play an event of a game at different times and/or oneuser can play an event of a game when the other user is not logged intoonline gaming service 110. Although illustrated as being included aspart of gameplay service 112, asynchronous gameplay coordination module120 can alternatively be implemented at least in part in gaming devices102.

Matchmaking service 114, when included in online gaming service 104,provides various functionality facilitating the finding of other userswith which a user of gaming device 102 can play a game. Matchmakingservice 114 identifies other users with which a particular user can playa game in a variety of different manners, such as based on physicallocations of the gaming devices 102, skill levels of the users of gamingdevices 102, and/or other characteristics of gaming devices 102 and/orthe users of gaming devices 102. Matchmaking service 114 can identifyother users based on user accounts that account access service 110 isaware of, based on users logged into their accounts at a particular time(e.g., as indicated by account access service 110), based on accountsfrom other services (e.g., social networking services that matchmakingservice 114 can communicate with), and so forth. Matchmaking service 114can identify other users with which a user of gaming device 102 can playa game across the same and/or different types of gaming devices 102(e.g., one or more users of a desktop computer and one or more users ofa game console, one or more users of a phone and one or more users of agame console, etc.). Similarly, matchmaking service 114 can identifyother users with which a user of gaming device 102 can play a gameacross the same and/or different services (e.g., one or more users ofgameplay service 112 and one or more users of another service of onlinegaming service 104). Asynchronous gameplay coordination module 120 canalso facilitate the finding of other users with which a user of gamingdevice 102 can play an event of a game asynchronously as discussed inmore detail below. Any finding of other users by matchmaking service 114is in addition to asynchronous gameplay coordination module 120 findingother users.

Each of services 110, 112, and 114 can be implemented using one or morecomputing devices. Typically these computing devices are servercomputers, but any of a variety of different types of computing devicescan alternatively be used (e.g., any of the types of devices discussedabove with reference to gaming device 102). Each of services 110, 112,and 114 can be implemented using different computing devices, oralternatively one or more of services 110, 112, and 114 can beimplemented using the same computing device.

Additionally, although services 110, 112, and 114 are illustrated asseparate services, alternatively one or more of these services can beimplemented as a single service. For example, gameplay service 112 andmatchmaking service 114 can be implemented as a single service.Furthermore, the functionality of one or more of services 110, 112, and114 can be separated into multiple services. In addition, thefunctionality of online gaming service 104 can be separated intomultiple services. For example, online gaming service 104 may includeaccount access service 110 and gameplay service 112, and a differentservice (e.g., a social networking service) can include matchmakingservice 114.

FIG. 2 illustrates an example gaming device and display in additionaldetail in accordance with one or more embodiments. FIG. 2 illustrates agaming device 202, which can be a gaming device 102 of FIG. 1, coupledto a display device 204 (e.g., a television). Gaming device 202 anddisplay device 204 can communicate via a wired and/or wirelessconnection. Gaming device 202 includes an asynchronous gameplaycoordination module 212 and an input/output (I/O) module 214.Asynchronous gameplay coordination module 212 is analogous toasynchronous gameplay coordination module 120 of FIG. 1, although isillustrated as implemented in gaming device 202 rather than in an onlinegaming service.

Input/output module 214 provides functionality relating to recognitionof inputs and/or provision of (e.g., display or other presentation of)outputs by gaming device 202. For example, input/output module 214 canbe configured to receive inputs from a keyboard or mouse, to identifygestures and cause operations to be performed that correspond to thegestures, and so forth. The inputs can be detected by input/outputmodule 214 in a variety of different ways.

Input/output module 214 can be configured to receive one or more inputsvia touch interaction with a hardware device, such as a controller 216as illustrated. Touch interaction may involve pressing a button, movinga joystick, movement across a track pad, use of a touch screen ofdisplay device 204 or controller 216 (e.g., detection of a finger of auser's hand or a stylus), other physical inputs recognized by a motiondetection component (e.g., shaking a device, rotating a device, etc.),and so forth. Recognition of the touch inputs can be leveraged byinput/output module 214 to interact with a user interface output bygaming device 202, such as to interact with a game, change one or moresettings of gaming device 202, and so forth. A variety of other hardwaredevices are also contemplated that involve touch interaction with thedevice. Examples of such hardware devices include a cursor controldevice (e.g., a mouse), a remote control (e.g., a television remotecontrol), a mobile communication device (e.g., a wireless phoneconfigured to control one or more operations of gaming device 202), andother devices that involve touch on the part of a user or object.

Input/output module 214 can also be configured to receive one or moreinputs in other manners that do not involve touch or physical contact.For example, input/output module 214 can be configured to receive audioinputs through use of a microphone (e.g., included as part of or coupledto gaming device 202). By way of another example, input/output module214 can be configured to recognize gestures, presented objects, images,and so forth through the use of a camera 218. The images can also beleveraged by gaming device 202 to provide a variety of otherfunctionality, such as techniques to identify particular users (e.g.,through facial recognition), objects, and so on.

Gaming device 202 can also leverage camera 218 to perform skeletalmapping along with feature extraction of particular points of a humanbody (e.g., 48 skeletal points) to track one or more users (e.g., fourusers simultaneously) to perform motion analysis. For instance, camera218 can capture images that are analyzed by input/output module 214 or agame running on gaming device 202 to recognize one or more motions madeby a user, including what body part is used to make the motion as wellas which user made the motion. The motions can be identified as gesturesby input/output module 214 or the running game to initiate acorresponding operation.

FIG. 3 illustrates an example system 300 implementing the asynchronousgameplay with rival display in accordance with one or more embodiments.System 300 includes an asynchronous gameplay coordination module 302(which can be an asynchronous gameplay coordination module 120 of FIG. 1or an asynchronous gameplay coordination module 212 of FIG. 2), a game304 and a game 306. System 300 can be implemented in a variety ofdifferent devices. For example, system 300 can be implemented in gamingdevices 102 of FIG. 1, in online gaming service 104 of FIG. 1, or partlyin gaming devices 102 and partly in online gaming service 104.

Game 304 includes one or more game modules 308, and game 306 includesone or more game modules 310. Games 304 and 306 are different games ofthe same game title (e.g., different games of the same car racing gametitle). The game modules 308 and 310 perform various functionality forthe games 304 and 306, respectively, and the specific functionalityperformed by game modules 308 and 310 varies based at least in part onthe particular game title.

In one or more embodiments asynchronous gameplay coordination module 302is implemented separately from, and as part of a service made availableto, games 304 and 306. Alternatively, asynchronous gameplay coordinationmodule 302 can be implemented (at least in part) in games 304 and 306.Thus, for example, modules 308 and/or 310 can include one or moremodules of asynchronous gameplay coordination module 302, or canimplement at least part of the functionality discussed herein asperformed by asynchronous gameplay coordination module 302.

Game 304 stores various game data in game data store 314, and game 306stores various game data in game data store 316. During operation,various information regarding a user can be stored as game data, such asthe user's performance in various events of the game, items or pointsaccumulated by the user during gameplay, and so forth. Althoughillustrated as separate game data stores, it should be noted that gamedata store 314 and game data store 316 can be the same game data store(e.g., implemented by online gaming service 104).

Games 304 and 306 have one or more events that a user can play. An eventis a particular part of a game that is played by a user. The nature of aparticular event depends on the particular game. For example, an eventof a racing game can be a particular track or course that is raced. Byway of another example, an event of a shooting game can be a particulartarget shooting course. It should be noted that a game can have a singleevent,

As a user plays an event of a game 304, data regarding the performanceof the user playing the event is recorded and stored as game data ingame data store 314. Similarly, as a user plays an event of a game 306,data regarding the performance of the user playing the event is recordedand stored in game data store 316. The data regarding the performance ofthe user playing an event refers to data indicating how the user playedthe event, and can vary based on the particular game. The data regardingthe performance of the user playing an event is sufficient to allow theplaying of the event by the user to be played back (replayed) at a latertime. For example, if the event is a track in a racing game, then theperformance of the user playing the event can include informationregarding the speed of the user's vehicle at various locations on thetrack, the direction the user's vehicle is pointing at various locationson the track, the position of the user's vehicle at various locations onthe track, any obstacles hit by the user's vehicle, and so forth.

In one or more embodiments, data regarding performance of a user playingan event is recorded, and data regarding one performance of the userplaying the event is maintained in game data store 314 or 316. If theuser plays the event multiple times, the performance of the user that isdeemed best by the game (or alternatively by the user) is theperformance that is maintained. Which performance is deemed best can bedetermined in different manners, such as being the performance thatresulted in the shortest time for the user for the event, theperformance that resulted in the highest score for the user for theevent, and so forth. Alternatively, data regarding any number ofperformances of the user playing the event can be maintained in gamedata store 314 or 316.

As discussed above, for a user playing a game 304 or 306 there is anobject in the game that represents the user. A user can optionally havemultiple objects that represent the user, and can select one or more ofthe multiple objects when playing a particular event of a game. Thisobject can be, for example, a vehicle (e.g., a car, boat, tank,motorcycle, spaceship, etc.), a character (e.g., a human, alien,monster, etc.), an orb or other symbol, and so forth. A user cancustomize the object that represents the user in various manners. Thecustomization of the object typically alters the appearance of theobject, although various features or capabilities of the rival can alsobe altered by the customization (e.g., performance of a vehicle orcharacter can be altered, weaponry or defensive characteristics of avehicle or character can be altered, etc.). For example, a vehicle canbe customized to have a particular paint job (e.g., colors, patterns,etc.), to have particular stickers or words written on the vehicle, toinclude particular components (e.g., chrome door handles, twin exhausts,particular wheels, etc.), and so forth. By way of another example, acharacter can be customized to have particular clothing, to haveparticular facial features (e.g., a beard, eyeglasses, etc.), to haveparticular items (e.g., a particular type of gun or other weapon), andso forth. Data indicating the manner in which the object representing auser is customized is stored as game data in game data store 314 or 316.This data can be subsequently retrieved, allowing the customized objectthat represents the user to be displayed at a later time.

Games 304 and 306 also support a currency (e.g., in-game currency) orcredit that is awarded to users for various actions. This currency orcredit can be used in different manners, such as to acquire additionalcustomization options for the object representing the user (e.g.,different components that can be added to a vehicle, different weapons),acquire additional objects representing the user (e.g., differentvehicles), and so forth.

In addition to a currency or credit, games 304 and 306 can also supportan experience point system that is awarded to users for playing thegame. These experience points can be awarded based on an amount of timethe user plays the game, the manner in which the user plays the game(e.g., which events the user plays), a distance covered in the game(e.g., how many miles of track the user has raced), and so forth.

Games 304 and 306 can also support various groups or clubs to which auser can belong. Which groups or clubs a user can join can be determinedin different manners. For example, a user may be allowed to join anygroup or club that he or she desires, a particular user that creates agroup or club may determine which other users can join that group orclub, users that are already a member of a group or club can vote todetermine whether another user can join the group or club, and so forth.The groups or clubs that a user is a member of can be stored in gamedata store 314 or 316.

It should be noted that various lists of users can be maintained byasynchronous gameplay coordination module 302 or other systems (e.g.,gameplay service 112 of FIG. 1 or other services of or accessible toonline gaming service 104 of FIG. 1). These lists can be maintained ingame data store 314 or 316, or alternatively other data stores (e.g.,implemented as part of or accessible to asynchronous gameplaycoordination module 302). These lists of users can include, for example,for each particular user a list of other users that the particular useris a friend with. The particular user can provide various inputsidentifying another user as a friend, and that other user can optionallyconfirm that he or she is a friend of the particular user before beingadded to the list of friends of the particular user. Friends of theparticular user can also be identified in other manners, such as from asocial networking service (e.g., accessible to online gaming service 104of FIG. 1). These lists can also include, for example, for eachparticular user a list of favorites of the particular user. A favoriteof a particular user refers to another user that the particular user hasidentified as a favorite (e.g., another users that the particular userhas indicated he or she enjoys playing against or watching play games).The other user can optionally confirm that he or she can be a favoriteof the particular user before being added to the list of favorites ofthe particular user.

Asynchronous gameplay coordination module 302 includes a game datasharing module 322, a rival selection module 324, and a notificationmodule 326. Generally, asynchronous gameplay coordination module 302allows a user to asynchronously play an event against another user.System 300 is discussed with reference to a user of game 304 playing anevent asynchronously against a user of game 306. However, it should benoted that a user of game 306 can similarly play an event asynchronouslyagainst a user of game 304, that a user of game 304 can similarly playan event asynchronously against another user of game 304, or that a userof game 306 can similarly play an event asynchronously against anotheruser of game 306.

Game data sharing module 322 facilitates sharing of game data fordifferent users, allowing one user to play an event against a previouslyrecorded playing of the event by another user. Rival selection module324 facilitates allowing a user to select another user to play an eventagainst asynchronously. Notification module 326 facilitates notifying auser when he or she has been beaten by another user from anasynchronously played event, and facilitates allowing the notified userto play the event again to respond to the challenge.

When a user desires to asynchronously play an event against another user(also referred to as a rival), the user provides an input requesting toselect a rival. Asynchronous gameplay coordination module 302 maintains,for each event of a game, a list of users that have played the event aswell as a score for the user playing the event. Module 302 can alsomaintain various additional information associated with the user, suchas a date and/or time the user played the event, a location or positionat which the object representing the user started and/or finished whenplaying the event, and so forth. This list of users can also include(explicitly or inherently) an indicator of the ranking of each user(e.g., a user with a higher score having a higher ranking than a userwith a lower score) for the event. The score for a user can take variousforms, such as a particular time taken to complete the event by theuser, a number of points accumulated by the user when playing the event.In response to the user input requesting to select a rival for an event,rival selection module 324 accesses a list of identifiers of users thathave played the event and their scores for the event.

In one or more embodiments, in response to the user input requesting toselect a rival for an event, rival selection module 324 automaticallyselects a rival for the user to play against asynchronously. Rivalselection module 324 can use various criteria to automatically select arival. For example, another user that has the next higher score (e.g.,the next faster time) than the requesting user can be automaticallyselected as the rival. By way of another example, another user that hasa score a threshold amount higher than the requesting user (e.g., a time2 seconds faster than the requesting user, a time that is 97% of therequesting user's time, etc.) is automatically selected as the rival.

In other embodiments, in response to the user input requesting to selecta rival for an event, rival selection module 324 displays or otherwisepresents at least a portion of the list of identifiers of users thathave played the event (and optionally the scores of those users for theevent). The full list of identifiers can be displayed, or the list ofidentifiers can be filtered based on various filter criteria so that theidentifiers of users that satisfy the filter criteria are displayed. Anymanner of grouping users supported by the game 304 or 306 can be used asa filter criteria. The requesting user can input a request to have thelist of identifiers filtered based on different filter criteria. Forexample, the filter criteria can be users that are friends of therequesting user (e.g., identified to system 300 by the requesting useras a friend of the user, identified as friends by another service (e.g.,a social networking service), and so forth), users that are members of aparticular group (e.g., a particular car club, a particular fan club),users that the requesting user has identified as favorites, the userswith the top scores for the event (e.g., the users with the top 10 ortop 50 scores), the users with scores for the event that are at least athreshold amount higher than the requesting user (e.g., a time 2 secondsfaster than the requesting user, a time that is 97% of the requestinguser's time, etc.), the users with scores for the event that are nearthe score of the requesting user (e.g., the ten closest in score higherand/or lower than the requesting user, the users with scores that arewithin a threshold amount higher than the requesting user, etc.), and soforth. The requesting user can input a request to have the list ofidentifiers filtered based on different filter criteria in differentmanners, such as by selecting a button or other identifier of filtercriteria displayed as part of a user interface, selecting one ofmultiple buttons on a controller with each button being associated withdifferent filter criteria, selecting a button on a controller thatcycles through different filter criteria, and so forth.

FIGS. 4 and 5 illustrate example user interfaces allowing a user toselect a rival to play an event against asynchronously in accordancewith one or more embodiments. FIG. 4 illustrates an example rivalselection user interface (UI) 402 in which a rival has beenautomatically selected for the requesting user. The user having the nexthigher score is identified as “User G”, and the score (a time of2:08:47, which refers to 2 minutes, 8 and 47/100 seconds (oralternatively other times, such as 2 hours, 8 minutes, and 47 seconds))of that user is displayed. Alternatively, the identifier of that usercan be displayed without the score of that user and/or displayed withvarious additional information associated with the user (e.g., the dateand/or time the user played the event, a location or position at whichthe object representing the user started and/or finished when playingthe event, etc.). The user can provide various user inputs to selectUser G, and begin playing the event against User G asynchronously. Rivalselection UI 402 can also optionally display an identifier of therequesting user (e.g., identified as “User A”) and/or the score of therequesting user.

A change rival button 404 is also displayed as part of rival selectionUI 402. The requesting user can select change rival button 404 to selecta different rival (e.g., based on different filter criteria as discussedabove). Although illustrated as a button 404, it should be noted that auser input requesting to select a different rival can be provided in avariety of different manners (e.g., pressing a particular button on acontroller, providing a particular hand gesture, and so forth). Inresponse to selection of the change rival button 404, rival selection UI502 of FIG. 5 is displayed.

Rival selection UI 502 lists various users and their associated scoresfor the event. Alternatively, identifiers of the users can be displayedwithout the scores of those users and/or displayed with variousadditional information associated with the users (e.g., for each userthe date and/or time the user played the event, a location or positionat which the object representing the user started and/or finished whenplaying the event, etc.). The user can provide various user inputs toselect one of the identified users, and begin playing the event againstthe identified user asynchronously. Rival selection UI 502 can alsooptionally display an identifier of the requesting user (e.g.,identified as “User A”) and/or the score of the requesting user. Theusers in rival selection UI 502 satisfy one or more filter criteria,which is the friends filter criteria in the illustrated example. In oneor more embodiments rival selection module 324 of FIG. 3 defaults todisplaying the users that satisfy the friends filter criteria, althoughother rival selection module 324 can alternatively default to displayingthe users that satisfy other filter criteria.

Rival selection UI 502 also displays a friends button 504, a top 10button 506, a club 1 button 508, a near me button 510, a favoritesbutton 512, and an automated button 514. Friends button 504 correspondsto friends filter criteria, and in response to user selection of button504 rival selection UI 502 displays the users that are identified asfriends of the requesting user. Friends button 504 is illustrated withcross-hatching to indicate that the friends filter criteria is currentlyselected.

Top 10 button 506 corresponds to filter criteria identifying the userswith the top 10 scores for the event, and in response to user selectionof button 510 rival selection UI 502 displays the users having the top10 scores for the event. Club 1 button 508 corresponds to filtercriteria identifying the users in a club or group identified as “Club1”, and in response to user selection of button 508 rival selection UI502 displays the users in the club or group identified as “Club 1”. Nearme button 510 corresponds to filter criteria identifying the users withscores for the event that are near the score of the requesting user, andin response to user selection of button 510 rival selection UI 502displays the users with scores for the event that are near the score ofthe requesting user. Favorites button 512 corresponds to filter criteriaidentifying favorites of the requesting user, and in response to userselection of button 512 rival selection UI 502 displays the users thatare identified as favorites of the requesting user.

Automated button 514 corresponds to automatic selection of a rival. Inresponse to user selection of button 514 rival selection UI 502 displaysrival selector UI 402 of FIG. 4.

Although illustrated as separate buttons in the user interface that canbe selected by a user, filter criteria can be selected in various othermanners. For example, in response to repeated user selection of a buttonon a controller, UI 502 can cycle through displaying users based ondifferent filter criteria (e.g., displaying the users having the top 10scores for the event in response to a first selection of the button,displaying the users in the club or group identified as “Club 1” inresponse to the next selection of the button, and so forth). By way ofanother example, various hand gestures can be used to select aparticular filter criteria, cycle through different filter criteria, andso forth.

Returning to FIG. 3, game data sharing module 322 facilitates sharing ofgame data for different users, allowing one user to play an eventagainst a previously recorded playing of the event by another user. Inresponse to a user of game 304 selecting a rival, rival selection module324 communicates an indication of the rival to game data sharing module322. Game data sharing module 322 in turn obtains the game data for therival for the event (e.g., from game data store 316), and provides thegame data for the rival for the event to game 304. The game data for therival includes the performance of the rival for the event as well asdata indicating the manner in which the object representing the rival iscustomized.

Game 304 proceeds to allow the user to play the event, controlling hisor her object in the event as if he or she were playing by himself orherself (or in real time against another user). Game 304 also playsback, while the user is playing the event, the object representing therival based on the performance data that is part of the obtained gamedata for the rival. Thus, the object representing the rival is displayedwhile the user is playing the game, providing an experience to the userthat is as if the user were playing against the rival in real time eventhough a recording of the rival's performance is being played back (andthe event is thus being played asynchronously). It should be noted thatthe behavior of the object representing the rival is based on theperformance data that is part of the obtained game data for the rival,not a generic or other artificial intelligence (AI) generated behavior.

Additionally, the object representing the rival played back by game 304for the event is the object as customized by the rival. Thus, ratherthan displaying a generic object as representing the rival, the objectas customized by the rival is displayed as representing the rival. Thus,the user is provided with an experience of playing against therival-specific object rather than some common or generic object.

For example, the event may be a particular track of a car racing game,and the user plays that event by racing his or her car on thatparticular track. The user can select a rival and have the car ascustomized by the rival displayed as another car that he or she racesagainst on that track. The performance of the rival's customized car onthe track is the performance of the car on the track when the rivalpreviously raced on that track.

Furthermore, in addition to the object representing the rival, one ormore additional objects that are game-controlled or are based on AIgenerated behavior can also be displayed. Continuing with the previousexample, in addition to the rival's customized car, one or moreadditional cars can also be displayed, with the user racing againstthese one or more additional cars as well as against the rival'scustomized car.

In one or more embodiments, the object representing the rival changesappearance based on a proximity in the game between the objectrepresenting the rival and an object representing the user. As theobjects are closer to one another the object representing the rivalbecomes more transparent, and as the objects are further away from oneanother the object representing the rival becomes less transparent (moreopaque).

Various different criteria or algorithms can be used to determine thetransparency of the object representing the rival. In one or moreembodiments, if the object representing the rival is at least athreshold distance away from the object representing the user in thegame (e.g., 50 feet on a racing track in the game, the length or size ofsome dimension of the object representing the user in the game, etc.),then the object representing the rival is opaque. If the objectrepresenting the rival is less than the threshold distance away from theobject representing the user in the game, then the object representingthe rival is transparent. The amount of transparency can be determinedlinearly (e.g., the transparency increases by 2% for each foot closerthan 50 feet the object representing the rival is to the objectrepresenting the user in the game), or alternatively using otherformulas. Thus, as the object representing the rival comes closer to theobject representing the user, the object representing the rival becomesmore transparent, and as the object representing the rival moves furtherfrom the object representing the user, the object representing the rivalbecomes less transparent (until the threshold distance is met at whichpoint the object representing the rival becomes opaque). Alternatively,a single transparency setting (e.g., 80% transparent) may be used, withthe object representing the rival being opaque if the object is at leasta threshold distance away from the object representing the user in thegame, and the object representing the rival being transparent (whateverthe single transparency setting is) if the object is not at least thethreshold distance away from the object representing the user in thegame.

For example, the event may be a particular track of a car racing game,and the user plays that event by racing his or her car on thatparticular track. While playing the game asynchronously against a rival,as the rival's car gets closer to the user's car, the rival's carbecomes more transparent, thus helping avoid confusion for the user onwhere his or her car is. However, as the rival's car gets further fromthe user's car, the rival's car becomes less transparent until a pointwhere the rival's car becomes opaque. Thus, when the rival's car isopaque, it appears to the user that he or she is racing against therival in real time.

Alternatively, other criteria or algorithms can be used to determine thetransparency of the object representing the rival. For example, twothreshold distances can be used, such as a close threshold distance(e.g., 20 feet on a racing track in the game), and a far thresholddistance (e.g., 50 feet on a racking track game). If the objectrepresenting the rival is at least the far threshold distance away fromthe object representing the user in the game, then the objectrepresenting the rival is opaque. If the object representing the rivalis less than the close threshold distance away from the objectrepresenting the user in the game, then the object representing therival is at a particular transparency level (e.g., 90% transparent). Andthe transparency level varies between the far and close thresholddistances (e.g., increasing linearly or according to some othercalculation as the distance changes from being at the far thresholddistance towards the close threshold distance).

It should be noted that, because game 304 plays back, while the user isplaying the event, the object representing the rival based on theperformance data that is part of the obtained game data for the rival,the object representing the user and the object representing the rivalcan overlap at times. For example, a car representing the user can be ata same location on a racing track as a car representing the rival, orthe car representing the user can be close enough to the carrepresenting the rival that the two cars overlap (e.g., the front end ofone car is at the same location on the racing track as the back end ofthe other car). However, as the rival's car gets closer to the user'scar the rival's car becomes more transparent as discussed above, thushelping avoid confusion for the user on where his or her car is.

It should also be noted that a user can play an event asynchronouslyagainst multiple rivals concurrently. A user can select multiple rivals,analogous to the selection of a rival as discussed above. Game data foreach of the multiple rivals is obtained, and while the user is playingthe event, for each of the multiple rivals the object representing therival is played back based on the performance data that is part of theobtained game data for the rival. Thus, for example, the event may be aparticular track of a car racing game, and the user plays that event byracing his or her car on that particular track. The user can selectmultiple rivals and have the cars as customized by the rivals displayedas other cars that he or she races against on that track. For each ofthe multiple rivals, the performance of the rival's customized car onthe track is the performance of the car on the track when the rivalpreviously raced on that track.

In one or more embodiments, additional information identifying the rivalcan be displayed to the user while playing the event asynchronouslyagainst the rival. This additional information can be provided to game304 along with the game data for the rival. For example, an identifierof the rival (e.g., a gamer tag or other identifier) can be displayed tothe user. This identifier can be displayed on or in close proximity tothe object representing the rival (e.g., on or above the rival'svehicle), or alternatively elsewhere.

FIGS. 6 and 7 illustrate an example of the changing of transparency ofan object representing a rival in accordance with one or moreembodiments. FIG. 6 illustrates an example game UI 600 for a racing gameincluding a car 602 representing the user of the game and a car 604representing the rival. In game UI 600, the distance between cars 602and 604 is at least a threshold amount, so car 604 is displayed asopaque. However, FIG. 7 illustrates an example game UI 700 for the racegame including cars 602 and 604 in which the distance between cars 602and 604 is not at least the threshold amount. Accordingly, car 604 isdisplayed as transparent.

Returning to FIG. 3, in one or more embodiments a user receives a bountyor reward based on his or her performance in playing the event and/or arating of how difficult the rival is to beat. The bounty or reward isprovided using the currency or other credit supported by the game. Theuser's performance in playing the event can be measured in differentmanners, such as based on simply whether the user beat the rival (e.g.,finished an event in a shorter amount of time than the rival orotherwise obtained a higher score than the rival) against which the useris playing the event asynchronously. The user's performance can also bemeasured in other manners, such as based on by how much the user beatthe rival (e.g., the difference in times or scores for the user andrival for the event), how close the user came to beating the rival(e.g., how close the user's time or score was to the rival's time orscore for the event), based on particular actions during performance ofthe game (e.g., obstacles avoided), and so forth. The rating of howdifficult the rival is to beat can be measured in different manners,such as a ranking of the rival, a difference in ranking between the userand the rival, and so forth.

The amount of the bounty or reward can vary, being based at least inpart on the user's performance in playing the event and/or a rating ofhow difficult the rival is to beat. For example, a user may be given abounty or reward of 50,000 credits if the rival had a ranking of 1, buta reward of only 1,000 credits if the rival had a ranking of 100. By wayof another example, a user may be given a bounty or reward equal to thedifference in rankings multiplied by 10 (e.g., if the user has a rankingof 900 and the rival has a ranking of 850, then the bounty or rewardwould be 500 credits (900−850=50, multiplied by 10 to get 500 credits)).By way of yet another example, a user may be given a bounty or reward of50 credits if the user does not beat the rival, but finished the eventin an amount of time or with a score that is within a threshold amountof the amount of time or score with which the rival finished the event.

In one or more embodiments, regardless of whether the user receives abounty or reward for playing an event, the user is still awardedexperience points for playing the event. The experience points can beawarded in different manners as discussed above, such as based on anamount of time the user played the event, a distance covered in playingthe event, and so forth.

Additionally, asynchronous gameplay coordination module 302 includesnotification module 326. When a user beats a rival in an event,notification module 326 sends a notification to the rival that he or hasbeen beaten. Notification module 326 can determine when a rival has beenbeaten in various manners, such as receiving an indication from a game304 or 306 that the user beat the rival, receiving an indication from amodule of gameplay service 112 of FIG. 1 that the user beat the rival,and so forth. The notification sent by notification module 326 can besent in various manners, such as using a messaging system provided bygameplay service 112, using a messaging system provided by game 304 or306, using a messaging system provided by another service (e.g., asocial networking service), and so forth. An indication of how to notifya particular user using a particular messaging system can be obtained invarious manners, such as being provided by the user and maintained byaccount access service 110 of FIG. 1.

The notification sent by notification module 326 includes auser-selectable link (e.g., a hyperlink) to the event that the rival wasbeaten in, and the user (the rival) can provide various inputs to selectthe link. The link identifies a location or functionality of gameplayservice 112 of FIG. 1 (e.g., of asynchronous gameplay coordinationmodule 120), and an identifier of the event that the rival was beaten inis embedded in the link or otherwise associated with the linked-tolocation or functionality. In response to user selection of the link,gameplay service 112 notifies a game 304 or 306 to jump to the eventthat the rival was beaten in, beginning running the game 304 or 306 (ornotifying a gaming device 102 of FIG. 1 to begin running the game 304 or306) if the game is not already running. The rival can then play theevent, attempting to better his or her score (e.g., obtain a higherscore). The rival can play the event individually, or alternativelyagainst one or more other users in real time or asynchronously (e.g.,the rival can select another user as a rival with which to play theevent asynchronously, another user (e.g., the user that beat the rivalresulting in the notification being sent by notification module 326)that is to be a rival with which to play the event asynchronously can beautomatically selected, and so forth).

The notification can optionally include various additional informationin addition to the user-selectable link. For example, the notificationcan include an identifier of the user that beat the rival, an identifierof the event in which the user beat the rival, an indication of thescore in the event obtained by the user that beat the rival, anindication of the score in the event obtained by the rival, and soforth.

For example, the event may be a particular track of a car racing game,and a user plays that event by racing his or her car on that particulartrack. In response to the user beating the rival (e.g., completing thetrack in a shorter amount of time than the rival), a notification issent to the rival. The rival receives, at his or her gaming device, thenotification that he or she has been beaten in the event. Thenotification includes a button or other link that the rival can select,in response to which his or her gaming device begins running the racinggame and jumps to the event in which the rival was beaten. The rival canthen begin playing the event himself or herself in an attempt tocomplete the track in a shorter amount of time. Thus, the notificationcan be displayed to the rival, and with simple selection of the buttonor link in the notification the rival can begin playing the event inwhich he or she was beaten.

Although the above discussions refer to sending a notification to therival that the rival has been beaten, similar notifications can be sentat other times. For example, if a rival is almost beaten (e.g., the usercomes within a threshold amount of time, score, etc. of beating therival in the event), then a notification can be sent to the rivalnotifying the rival that he or she was almost beaten in the event andincluding a user-selectable link (e.g., a hyperlink) to the event thatthe rival was almost beaten in.

FIG. 8 is a flowchart illustrating an example process 800 forimplementing the asynchronous gameplay with rival display in accordancewith one or more embodiments. Process 800 is carried out by a system,such as system 300 of FIG. 3, and can be implemented in software,firmware, hardware, or combinations thereof. Process 800 is shown as aset of acts and is not limited to the order shown for performing theoperations of the various acts. Process 800 is an example process forimplementing the asynchronous gameplay with rival display; additionaldiscussions of implementing the asynchronous gameplay with rival displayare included herein with reference to different figures.

In process 800, a user request to select a rival to play againstasynchronously for an event is received (act 802). The event can be anevent of a variety of different types of games as discussed above.

In response to the user request, a rival selector user interface isdisplayed (act 804). The rival selector user interface includes anidentification of one or more users that can be selected, and optionallyone or more filter criteria that can be selected as discussed above. Therival selector user interface can display a user that has beenautomatically selected as a rival or alternatively one or more usersthat satisfy particular filter criteria as discussed above.

A user selection of one of the one or more users is received (act 806).The user selection is a selection of one of the users identified in therival selector user interface as discussed above.

The selected user is used as the rival to play against asynchronouslyfor the event (act 808). The user from which the user request isreceived in act 802 can play against the rival asynchronously for theevent, with the previously recorded performance of the rival beingplayed back as the user plays the event as discussed above.

FIG. 9 is a flowchart illustrating an example process 900 forimplementing the asynchronous gameplay with rival display in accordancewith one or more embodiments. Process 900 is carried out by a system,such as system 300 of FIG. 3, and can be implemented in software,firmware, hardware, or combinations thereof. Process 900 is shown as aset of acts and is not limited to the order shown for performing theoperations of the various acts. Process 900 is an example process forimplementing the asynchronous gameplay with rival display; additionaldiscussions of implementing the asynchronous gameplay with rival displayare included herein with reference to different figures.

In process 900, a user request to play against a rival asynchronouslyfor an event is received (act 902). This user request can be, forexample, user selection of a rival as discussed above.

Game data for the rival for the event is obtained (act 904). The gamedata can include both a performance of the rival in the event and dataindicating a manner in which an object of the rival is customized by therival as discussed above.

While the user is playing the event, an object representing the rival isplayed back based on the obtained game data (act 906). The objectrepresenting the rival is played back as customized by the rival, andbased on the performance of the rival in the event as discussed above.

FIG. 10 is a flowchart illustrating an example process 1000 for usingnotifications in accordance with one or more embodiments. Process 1000is carried out by a system, such as system 300 of FIG. 3, and can beimplemented in software, firmware, hardware, or combinations thereof.Process 1000 is shown as a set of acts and is not limited to the ordershown for performing the operations of the various acts. Process 1000 isan example process for using notifications; additional discussions ofusing notifications are included herein with reference to differentfigures.

In process 1000, a determination is made that a rival has been beaten inan event (act 1002). The determination can be made in various manners asdiscussed above.

In response to the determination being made in act 1002, a notificationis sent to the rival including a link to the event (act 1004). Thenotification can be sent using various messaging systems as discussedabove.

An indication that the link has been selected by the rival is received(act 1006). The indication can be received, for example, by a gamingdevice, by an asynchronous gameplay coordination module (or other moduleof a gameplay service) from a gaming device used by the rival, and soforth.

The event in which the rival was beaten is jumped to so that the rivalcan play the event (act 1008). Jumping to the event includes running thegame (if not already running), and the game jumping to the event inwhich the rival was beaten as discussed above.

Various actions such as communicating, receiving, sending, recording,storing, generating, obtaining, and so forth performed by variousmodules are discussed herein. A particular module discussed herein asperforming an action includes that particular module itself performingthe action, or alternatively that particular module invoking orotherwise accessing another component or module that performs the action(or performs the action in conjunction with that particular module).Thus, a particular module performing an action includes that particularmodule itself performing the action and/or another module invoked orotherwise accessed by that particular module performing the action.

FIG. 11 illustrates an example computing device 1100 that can beconfigured to implement the asynchronous gameplay with rival display inaccordance with one or more embodiments. Computing device 1100 can, forexample, be a gaming device 102 of FIG. 1, implement at least part ofonline gaming service 104 of FIG. 1, be a gaming device 202 of FIG. 2,or implement at least part of system 300 of FIG. 3.

Computing device 1100 includes one or more processors or processingunits 1102, one or more computer readable media 1104 which can includeone or more memory and/or storage components 1106, one or moreinput/output (I/O) devices 1108, and a bus 1110 that allows the variouscomponents and devices to communicate with one another. Computerreadable media 1104 and/or one or more I/O devices 1108 can be includedas part of, or alternatively may be coupled to, computing device 1100.Processor 1102, computer readable media 1104, one or more of devices1108, and/or bus 1110 can optionally be implemented as a singlecomponent or chip (e.g., a system on a chip). Bus 1110 represents one ormore of several types of bus structures, including a memory bus ormemory controller, a peripheral bus, an accelerated graphics port, aprocessor or local bus, and so forth using a variety of different busarchitectures. Bus 1110 can include wired and/or wireless buses.

Memory/storage component 1106 represents one or more computer storagemedia. Component 1106 can include volatile media (such as random accessmemory (RAM)) and/or nonvolatile media (such as read only memory (ROM),Flash memory, optical disks, magnetic disks, and so forth). Component1106 can include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.)as well as removable media (e.g., a Flash memory drive, a removable harddrive, an optical disk, and so forth).

The techniques discussed herein can be implemented in software, withinstructions being executed by one or more processing units 1102. It isto be appreciated that different instructions can be stored in differentcomponents of computing device 1100, such as in a processing unit 1102,in various cache memories of a processing unit 1102, in other cachememories of device 1100 (not shown), on other computer readable media,and so forth. Additionally, it is to be appreciated that the locationwhere instructions are stored in computing device 1100 can change overtime.

One or more input/output devices 1108 allow a user to enter commands andinformation to computing device 1100, and also allows information to bepresented to the user and/or other components or devices. Examples ofinput devices include a keyboard, a cursor control device (e.g., amouse), a microphone, a scanner, and so forth. Examples of outputdevices include a display device (e.g., a monitor or projector),speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context ofsoftware or program modules. Generally, software includes routines,programs, applications, objects, components, data structures, and soforth that perform particular tasks or implement particular abstractdata types. An implementation of these modules and techniques may bestored on or transmitted across some form of computer readable media.Computer readable media can be any available medium or media that can beaccessed by a computing device. By way of example, and not limitation,computer readable media may comprise “computer storage media” and“communication media.”

“Computer storage media” include volatile and non-volatile, removableand non-removable media implemented in any method or technology forstorage of information such as computer readable instructions, datastructures, program modules, or other data. Computer storage mediainclude, but are not limited to, RAM, ROM, EEPROM, flash memory or othermemory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed by acomputer. Computer storage media refer to media for storage ofinformation in contrast to mere signal transmission, carrier waves, orsignals per se. Thus, computer storage media refers to non-signalbearing media, and is not communication media.

“Communication media” typically embody computer readable instructions,data structures, program modules, or other data in a modulated datasignal, such as carrier wave or other transport mechanism. Communicationmedia also include any information delivery media. The term “modulateddata signal” means a signal that has one or more of its characteristicsset or changed in such a manner as to encode information in the signal.By way of example, and not limitation, communication media include wiredmedia such as a wired network or direct-wired connection, and wirelessmedia such as acoustic, RF, infrared, and other wireless media.Combinations of any of the above are also included within the scope ofcomputer readable media.

Generally, any of the functions or techniques described herein can beimplemented using software, firmware, hardware (e.g., fixed logiccircuitry), manual processing, or a combination of theseimplementations. The terms “module” and “component” as used hereingenerally represent software, firmware, hardware, or combinationsthereof. In the case of a software implementation, the module orcomponent represents program code that performs specified tasks whenexecuted on a processor (e.g., CPU or CPUs). The program code can bestored in one or more computer readable memory devices, furtherdescription of which may be found with reference to FIG. 11. In the caseof hardware implementation, the module or component represents afunctional block or other hardware that performs specified tasks. Forexample, in a hardware implementation the module or component can be anapplication-specific integrated circuit (ASIC), field-programmable gatearray (FPGA), complex programmable logic device (CPLD), and so forth.The features of the asynchronous gameplay with rival display techniquesdescribed herein are platform-independent, meaning that the techniquescan be implemented on a variety of commercial computing platforms havinga variety of processors.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A method comprising: receiving a user request toselect a rival to play against asynchronously for an event of a game;displaying, in response to the user request, a rival selector userinterface that includes an identification of one or more users that canbe selected; receiving, a user selection of one of the one or moreusers; and using the selected user as the rival to play againstasynchronously for the event.
 2. A method as recited in claim 1, thedisplaying comprising displaying a first rival selection user interfacein which an identifier of an automatically selected rival is displayed,and in response to a user input displaying a second rival selection userinterface in which identifiers of multiple users that have played theevent are displayed.
 3. A method as recited in claim 2, the identifiersof the multiple users that have played the event being identifiers ofusers that have played the event filtered based on one or more filtercriteria.
 4. A method as recited in claim 3, the one or more filtercriteria comprising friends of the user from which the user request isreceived, the multiple users comprising users that have been identifiedas friends of the user.
 5. A method as recited in claim 1, furthercomprising providing the user from which the user request is received areward in credit supported by the game based on a performance of theuser in playing the event against the rival asynchronously.
 6. A methodas recited in claim 5, an amount of the reward being based on a rankingof the rival for the event.
 7. A method as recited in claim 1, furthercomprising sending, if the user from which the user request is receivedbeats the rival when playing against the rival asynchronously, anotification to the rival informing the rival that the rival has beenbeaten by the user in the event.
 8. A method as recited in claim 7,further comprising including in the notification a user-selectable link,and notifying the game of the rival to jump to the event in response toa selection of the user-selectable link.
 9. A method as recited in claim1, the game comprising a racing game, and the event comprising a trackof the racing game.
 10. A method as recited in claim 1, the usingfurther comprising, in response to user selection of one of the one ormore users: obtaining game data for the rival for the event, the gamedata including both a previously recorded performance of the rival inthe event and data indicating a manner in which an object of the rivalis customized by the rival; and playing back, while the user is playingthe event and based on the performance data, the object as customized bythe rival.
 11. A method as recited in claim 10, further comprisingincreasing, as the object as customized by the rival and an objectrepresenting the user become closer, a transparency of the object ascustomized by the rival.
 12. One or more computer storage media havingstored thereon multiple instructions that, when executed by one or moreprocessors of a gaming device, cause the one or more processors to:receive a user request to play against a rival asynchronously for anevent of a game; obtain game data for the rival for the event, the gamedata including both a previously recorded performance of the rival inthe event and data indicating a manner in which an object of the rivalis customized by the rival; and play back, while the user is playing theevent and based on the performance data, the object as customized by therival.
 13. One or more computer storage media as recited in claim 12,the multiple instructions further causing the one or more processors toincrease, as the object as customized by the rival and an objectrepresenting the user become closer, a transparency of the object ascustomized by the rival.
 14. One or more computer storage media asrecited in claim 12, the game comprising a racing game, the object ascustomized by the rival comprising a vehicle, and the customizationcomprising an appearance of the vehicle as altered by the rival.
 15. Oneor more computer storage media as recited in claim 12, the multipleinstructions further causing the one or more processors to provide tothe user a reward in credit supported by the game based on a performanceof the user in playing the event.
 16. One or more computer storage mediaas recited in claim 15, an amount of the reward being based on a rankingof the rival for the event.
 17. One or more computer storage media asrecited in claim 12, the multiple instructions further causing the oneor more processors to send, if the user beats the rival when playing theevent, a notification to the rival informing the rival that the rivalhas been beaten by the user in the event.
 18. One or more computerstorage media as recited in claim 17, the notification including auser-selectable link, and the multiple instructions further causing theone or more processors to notify a game of the rival to jump to theevent in response to a selection of the user-selectable link.
 19. One ormore computer storage media as recited in claim 12, the user requestincluding a user-selected rival from a set of identifiers of other usersthat have previously played the event.
 20. A method comprising:receiving a user request to select a rival to play againstasynchronously for an event of a game, the game comprising a racing gameand the event comprising a track of the racing game; displaying, inresponse to the user request, a rival selector user interface thatincludes an identification of one or more users that can be selected andone or more filter criteria that can be selected; receiving, a userselection of one of the one or more users to be the rival; obtain gamedata for the rival for the event, the game data including both apreviously recorded performance of the rival in the event and dataindicating a manner in which an object of the rival is customized by therival; and play back, while the user is playing the event and based onthe performance data, the object as customized by the rival, includingincreasing, as the object as customized by the rival and an objectrepresenting the user become closer in the game, a transparency of theobject as customized by the rival.